Data processing systems, such as microcontrollers, personal computers and computer networks are usually provided with some form of safety mechanism to ensure the integrity of data in the data processing device. Data stored in a data processing device may be vulnerable for a variety of reasons. For example, the status of a bit in a memory register may change in an unpredictable manner due to, for example, particle impact from, e.g., radiation. Furthermore, the status of individual bits or entire registers may be accidentally changed by faulty software. A third kind of risk may be produced by malicious software.
A context is a set of data associated with a task on a data processing device. The data processing system may be designed such that any task is allowed to access its own context but not any other context. The data of a specific task may thus be shielded against other tasks. Switching from one task to another task may involve storing the context of the current task, so that the current task may be resumed at a later point in time. A task may be an entire program, a thread, a subroutine, or a single instruction or any other kind of process on the data processing system. A task switch may therefore also be referred to as a context switch.
Data processing devices may be subject to functional safety standards, such as ISO 26262 or IEC 61508. There is therefore a need for a reliable scheme of detecting data corruption, notably in components that are relevant for functional safety. As mentioned above, data may be corrupted by, e.g., faulty software components. Data may even be corrupted by a lack of cooperation between software components. For example, a stack frame generated by a certain context may be corrupted by another context due to faulty software. Accordingly, there is a particular need for detecting corrupted stack frames and for providing stack-frame protection. The data that may be corrupted may include executable data, that is, program code. There is therefore a need for ensuring safe code execution.
One approach to improving the integrity of data in a data processing system involves the use of a checksum or a hash function. Checksums and hash functions are related mathematical concepts, and no distinction will be made between the two in this specification. The idea behind this approach may be seen in determining for a given data item (payload item) a signature in dependence on the data item in question. Identical payload items have identical signatures. Different payload items may have identical or different signatures. A signature function is a function that maps a set of payload items onto a set of signatures. A signature function is generally not bijective. The set of signatures may thus be smaller than the set of payload items for which the signature function is defined. Considering, for instance, a system with a word size of 32 bits, a signature function may be designed to protect individual data words. The signature function should thus assign a signature to each of the 232 different data words that may occur in the system. The signature may, for instance, have a length of seven bits. In this scenario, the signature function thus maps the set of 232 payload data words onto the set of 27=128 signatures. Comparing the signatures of two payload items provides a way of determining whether the two data items differ. Data items with different signatures necessarily differ. Payload items with identical signatures are, however, not necessarily identical, assuming that the signature function is non-bijective. For instance, considering again the example of 232 different payload items and 27=128 different signatures, the set of payload items may be partitioned into 128 subsets associated with the 128 different signatures, each subset containing those payload items that are mapped onto the same signature. In an example in which the 232 payload items are evenly distributed over the 128 subsets, there is thus a likelihood of 1 to 128 that the payload items from the set of 232 payload items belong to the same subset and thus have the same signature. The pair of data items consisting of the payload item and the corresponding signature may be referred to as a signed data item or as a protected data item. A valid signed data item is self-consistent in the sense that its signature component is the signature of its payload component. When the payload component is accidentally modified, there may be a substantial likelihood for the signed data item to become inconsistent. This likelihood may, for instance, be 127 out of 128 in the above-described example. Recomputing the signature for the payload component of a signed data item and comparing the recomputed signature to the signature component of the signed data item thus provides a way of checking the integrity of the respective signed data item.